home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1994 #2 / Monster Media No. 2 (Monster Media)(1994).ISO / maximus / wasup101.zip / NEWMODS.TXT next >
Text File  |  1994-06-23  |  5KB  |  92 lines
  1. What's Up Status System
  2. Copyright 1994 Arthur Ward
  3.  
  4. This document applies to the source code as it exists in the 1.xx versions.
  5. Theoretically it will remain the same long into the future.
  6.  
  7.  
  8.                       User contributed status modules
  9.  
  10.     If you have knowledge of C programming, you are welcome to write your
  11. own module to be included in What's Up in a new version. First off, this is
  12. open *only* for C code and nothing else (no C++, no Pascal, just straight
  13. C). Second, it should compile under Borland C++ 4.0 with a minimum of
  14. changes or else it may be rejected. Thirdly, it should use ANSI calls where
  15. possible. Finally, the Borland conditionals may be used if you need calls
  16. that are different between platforms, and you should also tell me if your
  17. code will only work under DOS or Windows, etc.
  18.  
  19.     *IMPORTANT*
  20.     Once contributed, your code is considered part of the project!
  21.     To keep things simple, any received donations will *not* be divided
  22.     among contributors! At any time in the future if this program becomes
  23.     commercial or shareware, income from purchases/registrations will not
  24.     be divided.
  25.     On the other hand, you will get a blurb in the docs as long as your
  26.     code/advice/whatnot is in use.
  27.     If you wish your source to remain non-public domain (ie. between the
  28.     people working on the What's Up projects only) in the event that other
  29.     sources are released, mark it clearly on everything.
  30.  
  31.     This policy may or may not change. Assume that you are releasing code
  32.     into the public domain for no charge when writing.
  33.  
  34.     The system is very easy to deal with: Your routine will be called every
  35. time the display is updated in order to generate an entirely new listing.
  36. There is no correspondence between one update and another, they are all
  37. generated fresh. Because your routine will be called at potentially high
  38. frequencies (once or twice a second, with others needing to run, plus
  39. display & time release to multitasker), it should work quickly.
  40.  
  41.     Configuration: Provide me with a list of items that needs to be filled
  42. from the configuration file, and I will add them to the configuration
  43. loader (easy). When naming your configurable variables, please remember
  44. that they must be public to all other modules, so use a unique name (like
  45. some mangled form of the software followed by the name of the data;
  46. BinkOutbound, MaxIPC are some that I use already). Currently only strings
  47. (copied from configuration as-is minus leading & trailing whitespace (as
  48. set by isspace() ) and unsigned integers have code. Others will require
  49. more time to implement.
  50.  
  51.     Source format: Your code may not remain in your source file! My style
  52. uses 4 space tab stops for grouping (ie. the inside of {}'d code, etc.),
  53. and when brief debugging status entries are needed from all of the modules,
  54. the DEBUG define will be declared. If your code uses multiple procedures,
  55. follow the guideline for configuration variables. When writing your module,
  56. I strongly encourage you *NOT* to do anything requiring one-time
  57. initalization/deinit setups, as there are not really any provisions for
  58. this. If you need memory for storage, I recommend alloca() and use the
  59. stack, although if you really need to, malloc() is OK as long as it is
  60. freed at the end of the module. Your module will be running in the LARGE
  61. model, so don't worry about farmalloc() or anything like that.
  62.  
  63.     Available What's Up calls:
  64.  
  65. void AddStatusItem(_status Status)
  66.  
  67.     AddStatusItem appends a new status entry to the status list, allocating
  68. memory as needed. All you do is fill a _status structure and pass it to
  69. AddStatusItem to have it displayed when the screen is redrawn following
  70. the completion of all status modules. If there is insufficent memory for
  71. AddStatusItem to complete the operation, it will simply ignore all new
  72. status entries. (meantime, it will have changed the last available entry to
  73. an error message so the user knows what has happened)
  74.  
  75.     Available structures 'n stuff:
  76.  
  77. typedef struct {
  78.     char    Name[ST_NAMELEN],          /* Name of program/user/whatever */
  79.             Status[ST_STATLEN];        /* Whassup */
  80. } _status;
  81.  
  82. Obviously, this is the structure that holds each entry. ST_NAMELEN and
  83. ST_STATLEN are two defines that contain the size of the Name & Status
  84. fields (respectively), including the null terminator.
  85.  
  86.  
  87. Ta-da, that's it. A whole 2 basic units to make this entire thing tick.
  88. Have fun.
  89.  
  90. Arthur Ward
  91. May 26, 1994 (revised slightly June 23)
  92.